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REMARKS 



Claims 1-27 are pending in the Application. 
Claims 1-27 stand rejected. 

I. REJECTION UNDER 37 C.F.R. S 101 

Claims 1-18 are rejected under 35 U.S.C. § 101 as being drawn to non-statutory 
subject matter. The Examiner asserts that claims 1-9 are directed to a search method 
which is nothing more than an algorithm or abstract idea and has no tangible or concrete 
embodiment, and produces no useful, tangible or concrete results. The AppKcants 
respectfully traverse the rejections of claims 1-18 under 35 U.S.C. § 101. 

Claim 1 is directed to a search method. The method includes determining if a first 
parameter has a first predetermined value, and if the first parameter has the first 
predetermined value, returning a value of each one or more selected members of the first 
node. The first node is referenced by a value of a first member of a second node in 
response to the first member of the second node having a predetermined type. 

The Applicants respectfully contend that the claimed inventions satisfy the test 
for statutory subject matter recited in In re Alappat, and repeated in State Street Bank 
& Trust Co, V. Signature Financial Group, and AT&T Corp, v. Excel 
Communications, Inc. In reAlappat, 33 F.3d 1526, 31 U.S.P.Q.2d 1545 (Fed. Cir. 
1994); State Street Bank & Trust Co. v. Signature Financial Group, Inc., 149 F.3d 
1368, 47 U.S.P.Q.2d 1596 (Fed Cir. 1998); AT&T Corp. v. Excel Communications, 
Inc., 172 F.3d 1526, 50 U.S.P.Q.2d 1547 (Fed. Cir. 1999). The claimed inventions 
produce a useful, concrete and tangible result in, inter alia, a return value for one or 
more selected members of a node in response to a search. 

The essential inquiry under In re Alappat is to determine whether the claimed 
subject matter as a whole is directed to a disembodied mathematical concept representing 
nothing more than a "law of nature" or an "abstract idea" or if, in contrast, the 
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mathematical concept has been reduced to some practical application rendering it useful. 
AT&T Corp.,ll2F, 2d 2d 1357, 50 U.S.P.Q.2d at 1451 (citing In re Alappat, 33 F 3d 
at 1543, 31 U.S.P.Q.2d at 1556-57). Moreover, in making the determination whether the 
claimed subject matter as a whole is a disembodied mathematical concept or if the concept 
has been reduced to some practical application rendering it useful, the claims must be 
construed in the light of the Specification. See, AT&T Corp,, 172 F.3d at 1357, 50 
U.S.P.Q.2d at 1451 (stating that more than an abstract idea was claimed in In re Alappat 
because the "claimed invention as whole was directed toward forming a specific machine 
that produced the useful, concrete and tangible resuk of a smooth waveform display) 
(emphasis supplied). The single claim at issue in In re Alappat was directed to a 
rasterizer and recited elements in means plus function form. In re Alappat, 33 F. 3d at 
1540, 31 U-S.P.Q.2d at 1555. Additionally, none of the limitations recited in the claim 
at issue e^ressly claimed a "smooth wave form display". Indeed, the concrete, useful and 
tangible result reUed upon in In re Alappat, namely, a smooth uniform display, appears 
in the background of the invention. Kuriappan P, Alappat, et al, U.S. Patent 
No. 5,440,676 (col. 1, lines 9-10). 

Likewise, in AT&T Corp. , the useful, nonabstract result relied upon in holding that 
the claimed invention was directed to statutory subject matter was that the PIC indicator 
therein held information about the call recipients PIC, which facilitated differential billing 
of long-distance calls made by a subscriber. AT&T Corp, 172 F.3d 1358, 50 U.S.P.Q.2d 
at 1452. However, the claim at issue in ^TcfeT Corp. was directed to a method including 
the steps of generating a message record for an interexchange call, and including in the 
message record a PIC indicator having a value which is a function of whether or not the 
interexchange carrier associated with the terminating subscriber is a predetermined one 
of the interexchange carriers. AT&T Corp., 172 F.3d at 1354, 50 U.S.P.Q.2d at 1449. 
Again, there was no express or explicit claim limitation directed to the useful, concrete, 
and tangible result relied upon in determining that the aforesaid claim was directed to 
statutory subject matter. See, Id. The relied upon PIC indicator that facilitates 
differential billing of long-distance calls appears, inter alia, in the summary of the 
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invention. Gerard P. Doherty, et al, U.S. Patent No. 5,333,184, col. 1, line 66 through 
col. 2, line 3. 

Likewise, in State Street Bank & Trust v. Signature Financial Group, a useful and 
concrete and tangible result not expressed in an explicit limitation in the claim at issue was 
relied upon in holding that the claim was directed to statutory subject matter. See, State 
Street Bank, 149 F.3d at 1373, 47 U.S.P.Q.2d at 1601 (holding that the transformation 
of data by the claimed data processing system produced a useful, concrete and tangible 
result, namely a final share price momentarily fixed for recording and reporting purposes). 
The claimed invention recited no limitation directed to either a final share price or means 
for momentarily fixing the final share price for recording and reporting purposes. See, 
State Street Bank, 149 F.3d at 1371, 47 U.S.P.Q.2d at 1599. Indeed, the relied upon 
useful, concrete and tangible result in State Street Bank, namely a final share price 
momentarily fixed, is not explicitly recited in the State Street Bank patent, but is 
effectively a distillation of the Summary of the Invention. See, R, Todd Boes, U.S. Patent 
No. 5,193,056, col. 4, lines 36-61. Thus, it is beyond peradventure that when judging the 
claimed subject matter as a whole to determine patentability under 35 U.S. C, § 101, the 
claims must be construed in the light of the specification. 

In short, the question whether a claim encompasses statutory subject matter 
focuses on the essential characteristics of the subject matter, in particular its utility. State 
Street Bank, 149 F.3d at 1375, 47 U.S.P.Q.2d at 1602. 

The Examiner contends that the claims are directed to an algorithm, or abstract 
idea or concrete embodiment and produces no useful result. (Paper No. 9, page 2.) 
These allegations are unavailing for several reasons. As discussed above, the assertion 
that the claim is directed to an algorithm does not address the essential inquiry under 35 
U. S . C § 101. The inquiry is not whether the claim recites an algorithm (all processes are 
in some sense an algorithm) but is there a practical application, or result. State Street 
Bank, 149 F.3d at 1373, 47 U.S.P.Q.2d at 1601. As discussed above, claims 1-18 are 



AUS9-2000-0761US1 



-4- 



f 



AUS9-2000-0761US1 



PATENT 



directed to a search method that produces a search result, in particular, values of one or 
more node members. 

The Examiner further asserts that claims 10-18, directed to a computer program 
product that include instructions for method steps that are nothing more than an algorithm 
that produces no useful, tangible or concrete result are non-statutory. (Paper No. 9, 
page 2.) Again, the Applicants respectfully disagree. The issue of a computer program 
product is statutory subject matter was settled in In re Beauregard, {In re Beauregard, 
53 F.3d 1583, 1584, 35 U.S.P.Q.2d 1383, 1384 (Fed. Cir. 1995)). In Beauregard, the 
USPTO agreed that a computer program product in a tangible storage medium is 
statutory subject matter. Id. at 1584, 35 U.S.P.Q.2d at 1384. There is no inquiry as to 
the nature of the programming contained in the conq^uter program product. See Id. 
Consequently, although the Applicants respectfully disagree that the programming 
instructions contained therein constitute nothing more than an algorithm that produces 
no useful result, such an inquiry is irrelevant under Beauregard. Therefore, the compute 
program product of claims 1 0- 1 8 is statutory subject matter, per se. 

Thus, for at least the aforesaid reasons, the Applicants respectfully contend that 
claims 1-28 constitute statutory subject matter. The Applicants respectfully request the 
withdrawal of the rejections of claims 1-28 under 35 U.S.C. § 101. 

11- REJECTION UNDER 35 U.S.C § 102 

Claims 1, 4, 6, 8-10, 13-15, 17-19, 22, 24, 26 and 27 have been rejected under 
35 U.S.C. § 102 as being anticipated by Traversal et al, U.S. Patent No. 6,366,954 
CTraver^ar). The Applicants respectfully traverse the rejection of claims 1, 4, 6, 8-10, 
13-15, 17-19, 22, 24, 26 and 27 under 35 U.S.C. § 102. 

Claim 1 is directed to a search method including determining if a first parameter 
has a first predetermined value, and, if the first parameter has the first predetermined 
value, the method returns the value of each of one or more selected members of a first 
node. The first node is referenced by a value of a first member of a second node in 
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response to the first member of the second node having a predetermined type. Claim 1 
has been rejected on the grounds that Traversat allegedly teaches determining if a first 
parameter, namely configuration request data such as a machine identifier, user name or 
user identifier, has a first predetermined value, for example a MAC address or user name. 

(Paper No. 9, page 3) (citing Traversat, FIGURE 7, step 706). However, FIGURE 7 
of Traversat discloses a methodology for accessing LDAP directory in a Java System 
Database (JSD) environment {Traversat FIGURE 7 and column 9, lines 23-25), In 
particular, step 706 discloses a step in which the JSD server determines whether data 
requested or needed by a client is in the JSD server schema. If so, the configuration data 
needed by the client is retrieved and, transmitted to the client (710). {Traversat, 
column 9, lines 44-49.) Thus, this step does not disclose determining if a first parameter 
has a first predetermined value. This step determines if data is available fi-om the JSD 
server. In other words, Traversat does not teach a step of determining if the value of a 
parameter is a first predetermined value but teaches determining where required to 
configure the client data is located. The Examiner then identifies the "Yes" branch from 
step 706 as a determination that the first parameter has a first predetermined value, 
wherein application specific configuration data is retumed (710). (Paper No. 9, page 3.) 

The application specific data allegedly discloses the value of one or more selected 
members of the first node. {Id) Plainly the "Yes" branch from step 706 is responsive to 
a determination that the configuration data needed by the cUent is available from the JSD 
server. This is not a determination that a first parameter has a first predetermined value. 

Additionally, the Examiner relies on teaching in Traversat directed to a 
hierarchical structure of an example namespace in a Java System Database (JSD) server 
schema. (Paper No, 9, page 3) (citing Traversat, column 8, lines 43-64). The machine 
namespace example contains three categories: a platform category (411), an identifier 
category (413), and a profile category (415). {Traversat, column 8, lines 16-64.) Under 
the identifier category are entries that contain a unique identifier for each computer in 
network such as the example network depicted in FIGURE 3 of Traversat, {Traversat, 
column 8, lines 33-35,) Under the profile category are entries that describe particular 
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categories or uses of computers in the network. (Traversat, column 8, lines 51-52.) 
Under this category is configuration information for particular profiles which can describe, 
for exan^le, departments within a company. {Traversal, column 8, lines 51-54.) 
Traversal fiirther teaches that under the finance profile example is application specific 
data (519) containing data related to the finance profile. {Traversal, column 8, lines 54- 
57.) Traversal fiirther describes that a specific identifier leaf node may be cross- 
referenced to a profile entry node if needed, that is, if a particular conputer has a certain 
profile. For example a computer used in the accoimting department or a computer that 
is strictly used as a receptionist terminal, may have a reference fi*om that computer's 
identifier to the appropriate profile entry. {Traversal, column 8, lines 57-64.) The 
Examiner relies on this teaching as disclosing the element of claim 1 in which the first 
node is referenced by a value of a first member of a second node in response to the first 
member of the second node having a predetermined type. (Paper No. 9, page 3.) 
However, this reliance is misplaced for several reasons. 

There is no disclosure of a methodology in conjunction with FIGURE 5. There 
is nothing being returned in conjunction with FIGURE 5, and in particular, there is 
nothing that discloses returning a value of each of one or more selected members of a first 
node in response to the first member of the second node having a predetermined type. 
Indeed, the Applicants note that there is no discussion of the cross-references as 
discussed in conjunction with FIGURE 5 of Traversal in association with methodologies 
described in FIGURES 7, 8, 10 or 1 1 . The Applicants fiirther note that this absence of 
the determining step as recited in claim 1 and the referencing of the first node by a value 
of a first member of a second node in response to the first member having a 
predetermined type is unremarkable. 

Traversal is directed to methods for exchanging data between a JSD entry and an 
LDAP directory service. {Traversal, column 1, lines 1-5.) In particular, Traversal is 
related to the transfer and arrangement of configuration data among components of 
storage areas in a computer network. {Traversal, column 1, lines 23-26.) In sum, the 
problem addressed by Traversal and the instant Application are completely different. 
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Therefore, there is no reason to expect that Traversat would disclose the invention of 
claim 1. 

Anticipation requires that a single prior art reference teach the identical invention 
as claimed. MPEP §2131. In other words, the reference must teach all of the limitations 
of the claim arranged as required by the claim. Id. Because, for the reasons discussed 
hereinabove, Traversat does not teach the identical invention of claim 1, claim 1 is not 
anticipated by Traversat. Therefore, claim 1 is allowable under 35 U.S.C. § 102 over 
Traversat, and the Apphcants respectfully request the withdrawal of the rejection of 
claim 1 under 35 U.S.C. § 102 over Traversat. 

Claim 4 is directed to the method of claim 1 and further including the step of 
returning values of a selected set of members of the second node. The Examiner relies 
on step 710 of FIGURE 7 as disclosing the limitation of claim 4. (Paper No. 9, page 4.) 
This teaching in Traversat discloses transmitting configuration data to the client if it is 
in the JSD server schema (when step 710 is reached via the "Yes" branch of step 706, or 
otherwise obtained fi-om the LDAP server (step 708) of FIGURE 7). {Traversat, 
column 9, lines 44-65.) Nothing in Traversat discloses that configuration data is a value 
of a selected set of members of a second node in which the first member has a 
predetermined type nor, as previously discussed, does Traversat teach that the second 
node has a first member having a value referencing the first node. Therefore, because 
anticipation requires that a single reference teach the identical invention as recited in the 
claim, Traversat does not anticipate claim 4. Therefore, claim 4 is allowable under 
35 U.S.C. § 102 over Traversat, and the Applicants respectfixlly request a withdrawal of 
the rejection of claim 4 over Traversat. 

Claim 6 is directed to the method of claim 1 and further including the step of, if 
the first parameter has the first predetermined value, returning a value of each of one or 
more selected members of a third node, the third node being referenced by a value of a 
first member of the first node in response to the first member of the first node having the 
predetermined type. Claim 6 has been rejected in the teaching in Traversat disclosing a 
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schematic diagram depicting the hierarchical structure of the MACHINE namespace 
discussed hereinabove in conjunction with claim 1 . (Paper No. 9, page 4.) Recall that 
there is no process described in conjunction with FIGURE 5. In particular, FIGURE 5 
and the associated description thereof includes no teaching with respect to a step of 
returning anything. (Traversat, column 8, lines 16-64.) FIGURES illustrates a 
hierarchical structure of an example JSD server schema namespace. Additionally, 
step 710 of FIGURE 7 of Traversat discloses transmitting configuration data to a client, 
however, there is nothing disclosed in Traversat describing the configuration data as a 
value of one or more selected members of a third node. {Traversal column 9, lines 44- 
65.) Consequently, Traversat does not teach the identical invention of claim 6. 
Therefore, Traversat does not anticipate claim 6 and claim 6 is allowable under 
35 U.S. C. § 102 over Traversat. The Apphcants respectfiilly request the withdrawal of 
the rejection of claim 6 under 35 U.S. C. § 102 over Traversat. 

Claim 8 recites the method of claim 1 in which the first parameter comprises a 
parameter of a set of parameters in a search request. Traversat is asserted to teach the 
limitation of claim 1 in step 704 of FIGURE 7. (Paper No. 9, page 4.) Traversat teaches 
that, a cUent computer boots up and a particular user logs on. {Traversat, column 9, 
lines 35-36; FIGURE 7, step 704.) Traversat fiirther teaches that the cHent computer 
accesses the JSD server to retrieve its configuration data and the configuration data for 
the user. {Traversat, column 9, lines 36-38.) Additionally, Traversat further teaches that 
the client computer accesses the JSD server to retrieve its configuration data and 
configuration data for the particular user. {Traversat, column 9, lines 35-38.) Plainly, 
Traversat does not teach a first parameter, as recited in claim 1, con:q)rising a parameter 
of a set of parameters in a search request, as recited in claim 8. There is nothing in the 
description of FIGURE 7 that discloses a set of search parameters, generally. {See 
Traversat, column 7, lines 23-65.) Traversat discusses a methodology for obtaining the 
configuration data fi-om the LDAP directory when it is not in the JSD server schema in 
conjunction with step 708 at FIGURE 10. {Traversal, column 9, lines 49-51; column 12, 
lines 1-31.) This is the use of a path name table to find a high level path in the LDAP 
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directory and performing a search under the high level path identified in the table. 
(Traversat, column 12, lines 1 5-3 1 .) It would be recognized by persons of ordinary skill 
in the relevant art that the search may be performed using the standard singleLevel 
or wholes subtree search scope in accordance with the LDAP specification. (See 
e.g. Heinz JOHNER, ET al, UM)ERSTAM)INgLDAP, 36-37 (1998).) Thus, Traversat does 
not teach, either explicitly or irrplicitly a first parameter as recited in claim 8 because there 
is no such parameter, either explicitly or implicitly, in Traversat whereby a value of a 
selected member of a first node is retumed if the first parameter has a first predetermined 
value. Because Traversat does not teach the identical invention of claim 8, it does not 
anticipate claim 8. Therefore, claim 8 is allowable under 35 U.S.C. § 102 over Traversat, 
the Applicants respectfully request the withdrawal of the rejection of claim 8 under 
35 U.S.C § 102. 

Claim 9 is directed to the method of claim 8 wherein the search request conprises 
a Lightweight Directory Access Protocol (LDAP) search request. The LDAP search as 
disclosed in Traversat has been discussed in conjunction with claim 8. While Traversat 
does disclose an example of a particular LDAP search for returning configuration data 
which is not found in the JSD server scheme, as discussed in conjunction with claim 8, 
such a search does not disclose the search method of claim 9, which incorporates the 
limitations of the claims from which it depends. Anticipation requires that the identical 
invention as recited in the claim be disclosed by the reference. Because Traversat does 
not teach the identical search method of claim 9, Traversat does not anticipate claim 9. 
Consequently, the Applicants respectfully request that the rejection of claim 9 under 
35 U.S.C. § 102 over Traversat be withdrawn. 

Claims 10, 13, 15, 17 and 18 have been rejected on the same ground as claims 1, 
4, 6, 8 and 9, respectively, as being drawn to a conputer program product including 
programming for performing operations paralleling the method steps of the respective 
ones of claims 1, 4, 6, 8 and 9. (Paper No. 9, page 4.) Similarly, claims 19, 22, 24, 26 
and 27 have been rejected on the same basis as claims 1, 4, 6, 8 and 9 respectively, as 
being drawn to a data processing system for performing operations paralleling the method 
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steps of respective ones of claims 1, 4, 6, 8 and 9. For the reasons discussed in 
conjunction with claims 1, 4, 6, 8 and 9 hereinabove, claims 10, 13, 15, 17, 18, 19, 22, 
24, 26 and 27 are also not anticipated by Traversat. The Applicants also respectively 
request the withdrawal of the rejection of claims 10, 13, 15, 17, 18, 19, 22, 24, 26 and 27 
under35U.S.C. § 102. 

HI. REJECTION UNDER 35 U.S.C. S 102 

Claims 1-27 have been rejected under 35 U.S.C, § 102 as being anticipated by 
Golla, et aL, U.S. Patent No. 6,587,874 ("Go//fl")- The Applicants respectfully traverse 
the rejection of claims 1-27 under 35 U.S.C. § 102, 

The limitations of claim 1 have been described hereinabove. Golla is directed to 
the use of hierarchical directories to aggregate configuration information for configuring 
network devices such as routers and switches. {Golla, column 1, lines 6-10.) Golla 
teaches a method for sequentially traversing a directory tree to retrieve configuration 
information for the network device being configured. (Golla, FIGURE 4; column 9, 
line 36 through column 10, line 25.) 

The Examiner asserts that the step in claim 1 of determining if a first parameter 
that has a first predetermined value is taught by step 403 of FIGURE 4 of Golla, (Paper 
No. 9, page 5.) This step, as taught by Golla is a step of identifying the leaf node 
corresponding to the network device under consideration. (Golla, column 9, lines 42-44.) 
The first parameter is identified as the request principal, and a first predetermined value 
is identified as a particular Distinguished Name (DN) attribute value. (Id.) The 
Applicants note that these identifications are an interpretation by the Examiner. In other 
words, Golla does not itself identify, for exanple, a particular DN attribute value as a 
predetermined value of a first parameter. Indeed, Golla teaches to the contrary. As 
previously noted, the network device being configured is identified as the "principal" in 
an LDAP request. Golla further teaches that the principal is also referred to as a 
Distinguished Name. (Golla, column 4, lines 37-38.) Golla further teaches, consistent 
with the LDAP specification, that the distinguished name, (DN) is a unique identifier of 
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an LDAP entry, (Golla, colimm4, lines 46-47; see also Heinz Johner, et al. 
Understanding LDAP, 20-21 (1998). Thus, it is not logical to interpret the identifying 
step of Golla with the determining step of claim 1 because determining whether the 
principal, or DN for the leaf node is itself, makes no sense. Therefore, Golla does not 
teach, and it is improper to interpret Golla as teaching the determining step of claim 1. 
Golla simply teaches that the principal of the network device is the DN of its leaf node 
and that DN is identified in the LDAP request in step 403. 

With respect to the step of returning a value of one or more selected members of 
the first node if the first parameter has the first predetermined value, the Examiner relies 
on the disclosure in Golla of the step of packaging and sending configuration parameters 
(417), if the leaf node is identified. As previously discussed, there is no step of identifying 
if a first parameter has a first predetermined value. The Examiner also interprets the 
conditional with respect to the first parameter having the first predetermined value as "if 
the leaf node is identified." (Paper No. 9, page 5.) However, there is no decisional step 
with respect to identification of a leaf node. Golla teaches identifying leaf node. As 
previously discussed, this is by application of the principal of the network device in the 
LDAP request. (Golla, column 9, lines 45-46.) There is nothing to be "determined" with 
respect to a first parameter in Golla. Again, this absence of such teaching in Golla is not 
remarkable. Golla is directed to configuring network devices, as previously discussed. 
Golla is not directed to the problems addressed by the instant Application. 

With respect to the elements in claim 1 in which the first node is referenced by a 
value of a first member of a second node, the Examiner identifies the second node with 
the identified leaf node, and the value of the first member referencing the first node as the 
particular DN. (Paper No. 9, page 5.) Again, the Applicants respectfiilly disagree. As 
taught in Golla and in accordance with the LDAP specification, the DN is the unique 
identifier of a node in the directory tree. That is, each node in the directory tree has a 
unique DN which identifies that node. Therefore, the attribute value of one node, say the 
first node, as recited in claim 1 , cannot under any circumstances be referenced by the DN 
of the second node. That notwithstanding, there is no teaching in Golla in which a first 
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node is referenced by a value of a first member of a second node. No such teaching 
would be expected As previously discussed, Golla, teaches simply a sequential traversal 
of a branch from a leaf node to the root of the directory tree, and such a traversal requires 
no operation of a first node being referenced by a value of a first member of a second 
node. Moreover, Golla does not teach this limitation whether in response to the first 
member of a second node having a predetermined type or otherwise. (With respect to the 
Examiner's assumption that the predetermined type is "non-root", the Applicants only 
note that there is no such determination made in Golla. Golla simply detects the root 
node (415) to terminate the recursive exploration of the directory tree from the leaf node 
for the device being configured to the root node of the tree. In other words, there is no 
need to determine if a node is of type non-root because starting from a leaf node assures 
that until the root node is reached. Golla, FIGURE 4; column 10, lines 18-19.) 

Thus, Golla fails to teach the identical invention of claim 1. Therefore, Golla 
does not anticipate claim 1. The Applicants respectfiiUy request the withdrawal of the 
rejection of claim 1 under 35 U.S.C. § 102 over Golla. 

Claim 2 is directed to the method of claim 1 and fiirther including the step of 
determining if a second member of the second node matches a value of a second 
parameter. The Examiner contends that this step is taught by the method of Golla 
discussed in conjunction with claim 1 by step 403 if another DN attribute value of the 
identified leaf node matches a value of a second parameter, namely another parameter of 
the LDAP request principal. (Paper No. 9, pages 5-6.) The Applicants respectfully 
disagree. As previously discussed, and as taught by the LDAP specification and Golla, 
a DN (that is the value of a DN attribute) is a unique identifier of a node in the directory 
tree. Therefore, the leaf node whose DN attribute is the principal of the LDAP request 
cannot have a second DN. Thus, the Examiner's interpretation of the teaching oi Golla 
is explicitly contradicted by the LDAP specification itself and the aforementioned teaching 
in Golla which discusses the architecture of an LDAP directory tree consistent with the 
LDAP specification. The foregoing notwithstanding, Golla does not teach a step of 
determining if a second member of the second node (as recited in claim 1) matches a value 
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of a second parameter. As previoxxsly described, Golla teaches sequentially traversing a 
branch of directory tree aggregating confirmation data. There is no reason for Golla to 
teach the limitation of claim 2, and does not do so. Because Golla does not teach the 
identical invention of claim 2, Golla does not anticipate claim 2. Therefore, claim 2 is 
allowable under 35 U.S.C. § 102 over Golla, and the Applicants respectfully request the 
withdrawal of the rejection of claim 2 under 35 U.S.C. § 102. 

Claim 3 further depends from claim 2 and is directed to the method thereof in 
which the step of returning the value of each of one or more members of the first node 
is in response to the second member of the second node matching the value of the second 
parameter. The Examiner asserts that the element of claim 3 is taught by the step of 
packaging and sending the configuration parameters (417) after the leaf node is found. 

(Paper No. 9, page 6.) However, there is no "finding of a leaf node." As previously 
discussed, the LDAP request principal identifies the leaf node corresponding to the 
network device being configixred, and indeed, Golla refers to this as an identifying step. 

{Golla, FIGURE 4.) In other words, there is nothing to be found because the 
methodology of Golla knows where to look. Moreover, as previously discussed, there 
is no matching of a leaf node to a second parameter. Therefore, there can be no returning 
step that is responsive to such a matching. Because Golla does not teach (nor would be 
expected to teach) the invention of claim 3, Golla does not anticipate claim 3. Therefore, 
claim 3 is allowable under 35 U.S.C. § 102 over Golla, and the Applicants respectfully 
request the rejection of claim 3 be withdrawn. 

Claim 4 depends fi-om claim 1 and recites the method thereof and fiirther including 
the step of returning values of a select set of members of the second node. Golla 
allegedly teaches the element of claim 4 in returning configuration parameters of the 
identified leaf node. (Paper No. 9, page 6 .) However, because the identified leaf node 
does not teach the second node as recited in claim 4 (through its dependency fi^om 
claim 1, it necessarily fails to teach returning a selected set of members of the second node 
as configuration parameters of the identified leaf node. Consequently, Golla does not 
teach the identical invention of claim 4. Because Golla does not, therefore, anticipate 
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claim 4, claim 4 is allowable under 35 U.S. C. § 102 over GoUa, and the Applicants 
respectfully request the withdrawal of the rejection of claim 4 under 35 U.S. C, § 102. 

Claim 5 is directed to the method of claim 4 and further including the step of 
determining if a second member of the second node matches a value of a second 
parameter and, in which the step of returning values of the selected step of members of 
the second node is in response to the second member of the second node matching a value 
of the second parameter. Claim 5 has been rejected on the same basis as claim 3, namely, 
that the determination if the second member of the second node matches a value of a 
second parameter is taught by finding the leaf node. (Paper No. 9, page 6.) As discussed 
in conjunction with claim 3, there is no teaching in Golla with respect to determining if 
a second member of a second node matches a value of a second parameter, and this is 
plainly not taught by the finding of a leaf node, in particular. Consequently, Golla does 
not teach the identical invention of claim 5, and thus, claim 5 is allowable under 
35 U.S.C. § 102 over Golla, The Applicants respectfully request the withdrawal of the 
rejection of claim 5 under 35 U.S.C. § 102. 

Claim 6 is directed to the method of claim 1 and further including the step of, if 
the first parameter has the first predetermined value, returning a value of each of one or 
more members of a third node, the third node being referenced by a value of a first 
member of the first node in response to the first member of the first node having the 
predetermined type. Claim 6 has been rejected on essentially the same argument as 
claim 1 with the third node identified as the parent of the leaf node's parent, and the third 
node being referenced by a value of the first member of the identified leaf node's parent, 
particularly a DN attribute value. (Paper No. 9, page 7.) However, as previously 
discussed, the DN attribute value of the identified leaf node's parent is the unique 
identifier of the identified leaf node's parent, and does not reference a third node. Indeed, 
under the Examiner's interpretation, Golla would not work because all the nodes in Golla 
would be the same node. Thus, Golla does not teach the identical invention of claim 6. 
Therefore, Golla does not anticipate claim 6, and claim 6 is allowable under 
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35 U-S.C. § 102 over Golla. The Applicants respectfully request the withdrawal of the 
rejection of claim 6 under 35 U.S.C. § 102. 

Claim 7 further depends from claim 6 and recites the method thereof in which 
selected members of the first node and the selected members of the third node are selected 
in response to a value of a second parameter. Claim 7 has been rejected on the same basis 
of claim 2 in which the members of the first node, that is the leaf node's parent, and the 
selected members of the third node, that is the leaf node's parent's parent are selected in 
response to a value of another DN attribute value of the identified leaf node. (Paper 
No. 9, page 7.) However, as discussed in conjunction with claim 2, there is no second 
DN attribute value of the identified leaf node. The DN attribute value of a node is unique. 
It uniquely identifies the node. Consequently, the Examiner's interpretation of the 
teaching of Golla is contrary to the LDAP specification. The foregoing notwithstanding, 
Golla does not teach selection in response to a value of a second parameter. Because 
Golla does not teach the identical invention of claim 7, Golla does not anticipate claim 7. 
Therefore, claim 7 is allowable under 35 U.S.C. § 102 over Golla and the Applicants 
respectfiiUy request the withdrawal of the rejection of claim 7 under 35 U.S.C. § 102. 

Claim 8 is directed to the method of claim 1 in which the first parameter 
conprises the parameter, of a set of parameters in a search request. The limitation of 
claim 8 is alleged to be taught by Golla in which the first parameter, namely, a parameter 
of an LDAP request principal, is a parameter of a set of parameters namely the principal, 
in a LDAP search request. (Paper No. 9, page 7.) The Applicants note that the LDAP 
request principal is the principal, and is the only search request parameter disclosed in 
Golla, To the extent that a set of parameters can have a single member, then perhaps, the 
LDAP request principal might con5)rise a parameter of a set of parameters. Nevertheless, 
because for the reasons discussed hereinabove, Golla does not teach the limitations of 
claim 1 from which claim 8 depends, Golla necessarily fails to anticipate claim 8. 
Consequently, claim 8 is allowable under 35 U.S.C. § 102 over Galls, and the Applicants 
respectfully request the withdraw of the rejection of claim 8 under 35 U.S.C. § 102. 
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Claim 9 further dq^ends from claim 8 and recites the method thereof in which the 
search request comprises an LDAP search request. The Applicants do not dispute that 
Golla teaches an LDAP search request. Nevertheless, because claim 9 incorporates the 
limitations of claims 8 and 1 from which claim 9 depends, and because these claims are 
not anticipated by Golla, claim 9 is also not anticipated by Golla, Therefore, claim 9 is 
allowable under 35 U.S.C. § 102 over Golla, and the AppUcants respectfiiUy request the 
withdrawal of the rejection of claim 9 under 35 U.S.C. § 102. 

Claims 10-18 have been rejected on the same basis as claims 1-9, respectively, as 
being drawn to a computer program product, including programming for performing 
operations paralleling the method steps of the respective ones of claims 1-9. Thus, for 
at least those reasons discussed in conjunction with claim 9, the Apphcants also 
respectfixUy assert that Golla does not anticipate claims 10-18. Therefore, claims 10-18 
are allowable under 35 U.S.C. § 102 over Golla, and the Applicants respectfully request 
the withdrawal of the rejection of claims 10-18 under 35 U.S.C. § 102. 

Claims 19-27 also have been rejected on the same basis as claims 1-9, 
respectively, as being drawn to a data processing system for performing operations 
paralleling the method steps of the respective ones of claims 1-9. Therefore, for the 
reasons discussed in conjunction with claims 1-9, claims 19-27 are also allowable under 
35 U.S.C. § 102 over Golla, and the Applicants respectfiilly request the withdrawal over 
the rejection of claims 19-27 under 35 U.S.C. § 102. 

rV. CONCLUSION 

As a resuh of the foregoing, it is asserted by the Applicants that the remaining 
claims in the Application are in condition for allowance, and respectfully request an early 
allowance of such claims. 

Applicants respectfully request that the Examiner call Apphcants' attorney at the 
below hsted number if the Examiner believes that such a discussion would be helpful in 
resolving any remaining problems. 
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Respectfully submitted, 

WINSTEAD SECHREST & MINICK P C. 

Attorney for Applicants 
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